Technical Planning

About

image of employees sorting post-it notes on wallThe Technical Planning process provides a framework to define the scope of the technical effort required to develop, deploy and sustain the system, and provides critical quantitative inputs to program planning and life-cycle cost estimates. Technical planning provides the Program Manager (PM) and Systems Engineer with a framework to accomplish the technical activities that collectively increase product maturity and knowledge and reduce technical risks. Defining the scope of the technical effort provides:

The resulting program cost estimates and risk assessments are essential to support milestone decisions, establish the plan for accomplishing work against which contract performance is measured and enable mandatory program certifications (e.g., 10 USC 4252).

Technical planning includes the program’s plan for technical reviews and audits (see E Guidebook, Section 3). It should also account for resources (skilled workforce, support equipment/tools, facilities, etc.) necessary to develop, test, produce, deploy and sustain the system.

Technical planning should be performed in conjunction with, and address, key elements and products governing other SE processes to ensure the program’s technical plan is comprehensive and coherent. For example, it should be used with the Technical Assessment process to evaluate the progress and achievements against requirements, plans and overall program objectives. If significant variances are detected, this process includes appropriate re-planning.

Role of the PM and SE

The PM and Systems Engineer should ensure technical planning remains current throughout the acquisition life cycle. They should initiate technical planning activities early in the life cycle before the Materiel Development Decision (see Engineering of Defense Systems Guidebook, Section 2 Pre-Materiel Development Decision Engineering). Beginning in MSA, programs begin to capture their technical planning in the Systems Engineering Plan (SEP) (see SE Guidebook, Section 1.5 Systems Engineering Plan), which is required at each milestone review from Milestone A to Milestone C.

Technical planning leverages the Concept of Operations/Operational Mode Summary/Mission Profile (CONOPS/OMS/MP), and mission analysis. The CONOPS/OMS/MP is a document consistent with the validated/approved capability requirements document to include the operational tasks, events, durations, frequency, operating conditions and environments under which the recommended materiel solution is to perform each mission and each phase of a mission.

As the system matures and issues arise throughout the life cycle, the PM and Systems Engineer should consistently look for root cause(s) and implement corrective actions in order to enable programmatic and technical success. Modifications to the SE processes and SEP may be required because of root cause and corrective action analysis and implementation. Mission analysis includes all affected operational missions and phases (including degraded modes of operation), where system missions are analyzed and human/machine factors necessary to achieve performance requirements are assessed, and any lessons learned from legacy systems and mission-essential task lists are reviewed.

Activities and Products

The PM is ultimately responsible for the development, management and execution of all program plans. The Systems Engineer is responsible for:

Activities

Technical Planning should reflect the context of the organization and comply with all applicable policies. The PM, Systems Engineer, and Lead Software Engineer should consider all relevant constraints when identifying technical tasks, sequencing these tasks and estimating resources and budgets. Inputs to the technical planning process vary over time as the program evolves and the system matures. Technical Planning includes the following activities:

Considerations

Key factors that the Systems Engineer should consider when accomplishing technical planning include:

Products

In addition to the SEP, the technical planning effort supports the development of the following documents:

Other useful resources available to assist the PM and Systems Engineer in the Technical Planning process can be found in the OUSD(R&E) Systems Engineering & Architecture website.

Products and Tasks

Select an item below to expand.

  1. Identify stakeholders who will use the systems engineering plan (SEP).
  2. Determine and track alignment of the program’s SEP with the system developer’s systems engineering management plan (SEMP), and recommend corrections for SEMP items not aligned with the SEP to the contractor.
  3. Identify and document SEP update criteria.
  4. Incorporate the stakeholder information, SEP / SEMP comparisons and SEP update criteria into the Introduction section of the SEP.
  1. Identify the architecture products that will be developed.
  2. Document the system’s physical interfaces architecture diagram.
  3. Identify the acquisition approach for developing and documenting software architecture priorities.
  4. Identify the acquisition approach for defining requirements for architecture products.
  5. Identify the acquisition approach for linking engineering and architecture activities.
  6. Develop the tabular documentation of the system-level technical certifications which must be obtained during program’s life cycle.
  7. Incorporate the architecture products approach, software priorities, engineering and architecture linkage, and system-level technical certifications table into the program technical requirements section of the systems engineering plan (SEP).
  1. Identify the engineering and management resources necessary to account for management of technical schedule planning and execution of program tasks.
  2. Identify and summarize the program oversight and management systems that will integrate cost, schedule, and technical performance goals, metrics, and resources.
  3. Diagram the process for how the program plans to manage engineering and integration risk and how these processes will be integrated with those of the contractor(s).
  4. Identify and diagram the acquisition’s technical staffing plan.
  5. Obtain diagrams of the contractor’s program office organization and staffing plan.
  6. Identify the detailed processes to be used to document, facilitate, and manage interaction among the systems engineering (SE) team(s) down to and including subcontractors.
  7. Identify the program’s strategy for identifying, prioritizing, and selecting the set of metrics for monitoring and tracking program SE activities and performance.
  8. Incorporate the resource requirements, program oversight systems, risk process diagrams, staffing diagrams, integration process descriptions and metrics strategy into the engineering resources and management section of the systems engineering plan.
  1. Identify and document system-level technical reviews conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
  2. Identify and document trade studies conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
  3. Identify and document independent reviews conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
  4. Identify key planned system engineering, integration, and verification processes and activities established or modified since the previous acquisition phase, including updated risk reduction and mitigation strategies and technical and manufacturing maturity.
  5. Identify and document graphically how top-level requirements will be traced from the source joint capabilities integration and development system (JCIDS) documents down to configuration item (CI) build-to specifications, and verification and validation (V&V) plans.
  6. Document how requirements will be managed, including how requirements changes will be made and tracked.
  7. Document the program management office’s (PMO’s) plans for conducting each upcoming technical review, along with identified entry/exit criteria.
  8. Identify and describe planned or established technical baseline artifacts.
  9. Identify and document graphically how the program will maintain configuration control of its technical baselines.
  10. Identify and develop the tabular documentation for design considerations that are critical to the achievement of the program’s technical requirements.
  11. Identify and develop the tabular documentation for reliability and maintainability engineering activities.
  12. Identify and develop the tabular documentation for engineering tools to be used to manage the technical effort for the program.
  13. Incorporate the acquisition’s reviews, process modifications, technical review plans, configuration control plans, and related diagrams into the technical activities and products section of the systems engineering plan.

Source: AWQI eWorkbook

Resources

Key Terms

Source:
DAU ACQuipedia
DAU Glossary

Policy and Guidance

DAU Training Courses

DAU Tools

DAU Media

On this page

  1. About
  2. Role of the PM and SE
  3. Activities and Products
  4. Resources
Back to top